Cormac Hogan, известный специалист в области виртуальных хранилищ на платформе VMware vSphere, выпустил интересное видео об использовании постоянных томов (Persistent Volumes) в качестве файловых шар для кластеров Kubernetes:

В качестве бэкенда таких томов используются файловые шары кластеров VMware vSAN, которые позволяют администраторам Kubernetes контролировать их использование со стороны инфраструктуры контейнеризованных приложений. В видео рассказано о том, как предоставлять права доступа (read only, read/write) на базе параметров сетей, которые получают доступ к томам. Также у Кормака есть детальная статья о том, как эти права доступа настраивать.

Из видео вы узнаете, как шаг за шагом настраивать доступ к томам через конфигурационный файл CSI-драйвера и контролировать сетевой доступ в томам через службы vSAN File Services.

В середине июля компания VMware выпустила обновление своей главной платформы для виртуализации и доставки десктопов и приложений VMware Horizon 8 (2106). Напомним, что год назад о версии Horizon 2006 мы писали вот тут.

Давайте посмотрим, что нового появилось в Horizon 8 / 2106:

Основные улучшения

• Поддержка Horizon 7.10 и 7.13 была расширена до 17 марта 2022 и 15 октября, соответственно
• Новые рекомендации о Horizon Agent говорят о том, что теперь не нужно переустанавливать Horizon Agent для апгрейда VMware Tools, если вы соблюдаете условия interop matrix

Обновления платформы

• Поддержка 20 тысяч сессий на один модуль Pod
• Поддержка миграции VMware Update Manager для порт-групп с NSX VDS на NSX CDS
• Дополнительные REST API endpoints, которые дают функции федерации доступа, Event DB API, поддержку RBAC через REST API и многое другое

Блокирование функций снимков экрана

Теперь для сессий десктопов Horizon администраторы могут отключать функцию снимков и записи экрана, что могло привести к краже данных со стороны пользователей. Опция поддерживается только на Windows-агентах. Делается это путем установки значения 1 в следующем ключе реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Vmware, Inc.\Vmware VDM\Agent\Configuration\Screen-capture Blocking

Пока для HTML5-доступа она не поддерживается, но сам этот HTML5-доступ можно просто отключить. Блокируются только снимки через View Client, а для их отключения в самой гостевой ОС нужно использовать рекомендации Microsoft.

Мгновенные клоны

Теперь Sysprep можно использовать для объектов Instant Clones без родительских ВМ. Это может привести к падению скорости развертывания и большему числу перезагрузок. Зато у вас будет новый SID и такая же функция, которая есть и у связанных клонов.

Здесь появилось несколько значимых улучшений:

• Выбор типа vCenter для Cloud Burst - теперь можно выбирать способ управления онпремизными ресурсами Cloud Burst, которые должны удовлетворять требованиям 120 мс между агентами и Connection Server. Таким образом, вы можете использовать vCenter вашего стороннего облачного датацентра для управления ресурсами Horizon через Connection Server. Теперь нет необходимости развертывать Pods в публичном облаке только под средства управления.

• Возможность постоянного доступа к приложениям (Forever Application Sessions) - это нужно для таких сервисов, как онлайн-дэшборды, трекинг состояния (например, пациентов), тикеры акций и т.п. Эти сессии можно настроить на уровне пула/фермы или в глобальных настройках. Они поддерживают аутентифицированных пользователей на Windows и Linux клиентах.
• При создании пулов Full Clone и Managed Manual Desktop можно выбрать разрешения 5К и 8К для клиентов Blast. Максимум можно использовать 2 монитора. Для PCoIP поддерживается только 4К.

• Новые способы аутентификации для Untrusted Domains:
  • SAML
  • True Single Sign-On
  • Smart card

В новой версии коннектора есть следующие нововведения:

• Теперь можно иметь несколько узлов stateless connector. Horizon Cloud Connector служит как узел для контейнеров Kubernetes, которые выполняют критические сервисы Horizon.
• Service-level fault tolerance - теперь для сервера лицензий работают функции непрерывной доступности.
• Теперь для лицензий поддерживаются SNMP traps, такие как проблемы с синхронизацией и нотификации о событиях жизненного цикла.

• Windows Agent - он получил поддержку Windows Server 2022, а также улучшения механизма сбора данных, которые используются для мониторинга и траблшутинга. Data collection logging устанавливается по умолчанию и может быть включен через ключ реестра.
• Linux Agent -тут сразу несколько новых возможностей:
  • Linux Smartcard redirection - поддержка этого механизма доступна на десктопах Red Hat Enterprise Linux со включенным Security-Enhanced Linux.
  • Digital watermark - поддержка водяных знаков для сессий Linux, что позволяет защищать интеллектуальную собственность.
  • Поддержка Red Hat Enterprise Linux 8.4 (Workstation и Server), а также CentOS 8.4.

Тут появились следующие вещи:

• Поддержка Xbox One для Windows-клиентов
• Возможность изменять audio sample rate, которая сохраняется между сессиями
• Возможность использовать 6 мониторов в режиме 4К
• Возможность использовать GPU encoding для режима session collaboration на Windows 2004 и более поздних

Также появились улучшения Copy/Paste - теперь можно использовать Clipboard Redirection для отключения и включения операций copy-paste в рамках сессии:

Кроме того, в этой категории есть дополнительные улучшения:

• Поддержка 48khz аудио через RTAV (по умолчанию 16khz)
• Улучшения copy/paste для медленных сетей
• Эмуляция кэширования сертификатов смарт-карт для не-Windows клиентов
• Упрощенный мониторинг задач печати (для очереди отображается имя пользователя в сессии)
• Поддержка функций Microsoft Edge Chromium:
  • HTML5 Multimedia Redirection
  • Browser Redirection
  • Geolocation Redirection
  • USB Redirection

Улучшения протокола Blast

Тут довольно много всего нового:

• Функции Blast Virtual Channel security
• Улучшения кодека Blast, включая скорость работы клиентов и улучшения сжатия текста
• Улучшения планировщика frame scheduler, который повышает масштабируемость и уменьшает latency
• Оптимизация создания воркеров Blast
• Поддержка GPU NVIDIA Ampere A10 и A40
• Улучшенная работа кодека NVIDIA GPU при удаленном соединении через Horizon Agent
• Поддержка видео 10-bit HDR 4:2:0 для Windows 10 Agent и Client, а также ВМ с NVIDIA vGPU
• Поддержка видео 10-bit HDR 4:4:4 для Windows 10 Agent и Client, ВМ с NVIDIA vGPU, а также клиентов Intel (Ice Lake+)

Оптимизации Microsoft Teams

Тут появились следующие фичи:

• Обновления WebRTC
• Поддержка Linux для оптимизаций Microsoft Teams
• Поддержка опции Mac Client readback
• Динамическое разрешение видео на базе производительности CPU тонких клиентов
• Улучшенные функции screen sharing для Mac и Linux
• Поддержка Mac для оптимизаций Microsoft Teams как remote app

Групповые политики

Теперь для браузера Microsoft Edge (Chromium) поддерживаются следующие групповые политики:

• Включение HTML5 Multimedia Redirection
• Включение VMware Browser Redirection
• Включение VMware Geolocation Redirection (поддерживается также и для UPD-печати)
• Возможность определить дефолтные настройки для UPD-принтеров
• Поддержка Agent Configuration - настройки для сессий RDS
• Unity Touch and Hosted Apps  - новая настройка "Redirect legal notice messages as a window"
• Поддержка Screen-capture Blocking (см. выше)
• Настройка Sample Rate – Recording Audio Device - устанавливает частоту сэмплирования для хостов RDS и опубликованных приложений.

В следующей статье мы посмотрим на новые возможности клиентов VMware Horizon Clients для различных платформ. А пока вы можете загрузить новую версию VMware Horizon 8 (2106) по этой ссылке. Release Notes доступны тут.

На днях компания VMware объявила о доступности решения NSX Advanced Load Balancer (продукт купленной компании Avi Networks) для гибридной инфраструктуры с облачной частью на базе Azure VMware.

NSX Advanced Load Balancer (Avi) позволяет организовать работу Enterprise-приложений с функциями локальной балансировки нагрузки, а также глобальной балансировки (global server load balancing, GSLB) и сетевого экрана Web Application Firewall (WAF) для нагрузок, исполняемых в облаке Azure VMware.

Avi дает функции балансировки нагрузки в гибридной среде для приложений, которые переезжают в облако Azure, с возможностями динамического масштабирования и нативными функциями облачной автоматизации.

Особенности данного решения:

• Полностью программное решение с функциями GSLB и WAF.
• Возможности Cloud-native развертывания и управления с удобным расширением мощности балансировщика.
• API для команд DevOps, удобные SDK (Python / Go / Java) и управление конфигурациями на базе Infrastructure-as-a-Code (Ansible, Terraform).
• Бесшовная доставка приложений как в облачную среду, так и в онпремизный датацентр.
• Возможности мониторинга и обнаружения, позволяющие быстро решать возникающие проблемы, а также интеграция со сторонними решениями через REST API.

Основные инфраструктурные возможности:

• Lift-and-Shift: При перемещении нагрузок из онпремизного датацентра в облачный на базе Azure VMware вы получаете Enterprise-балансировщик в публичном облаке.
• Data-center Extension: Avi дает новые возможности виртуальному датацентру, такие как GSLB и WAF, где есть шаблоны доступности приложений, а также поддержка топологий Active-Active (со множеством опций) и Active-Standby.
• Disaster Recovery: Avi поддерживает сценарии BC/DR для доступности приложений, как при локальной балансировке, так и для GSLB.

В рамках решения компоненты Avi Controller, NSX Manager и VMware vCenter на базе Azure VMware интегрированы в единое решение по балансировке трафика:

Avi использует режим NSX-T Cloud Connector, что позволяет унифицировать инфраструктуру балансировки в рамках гибридного облака:

Развертывается решение в виде виртуального модуля (Virtual Appliance) компонента Avi Controller с помощью несложного мастера:

Он может быть развернут как в онпремизной инфраструктуре, так и в облаке Azure VMware Solution SDDC, единственное требование - это выделенный IP для:

• Коммуникации с NSX Manager и vCenter
• Развертывания компонентов Service Engines в инфраструктуре Azure VMware Solution SDDC

Чтобы настроить Avi на базе Azure вам надо создать новый Cloud Connector внутри Avi Controller:

Этот коннектор взаимодействует с компонентами инфраструктуры, чтобы обнаружить сетевые и вычислительные ресурсы и автоматизировать развертывание Avi Service Engines (сущности, которые реализуют службы балансировщика).

Так как облачное решение Azure VMware построено на базе стека VMware Cloud Foundation с решениями NSX и vCenter, Avi использует стандартный NSX-T Cloud Connector.

Затем в интерфейсе создается Virtual Service, который имеет front-end IP приложения, за которым расположены члены пула или серверы приложений:

Avi также поддерживает политики Layer 7 request and response, разные алгоритмы балансировки, мониторинг состояния компонентов и многое другое.

Как только вы создали Virtual Service, Avi Controller развертывает Service Engines в датацентре, после чего проверяет, что сервис может обслуживать трафик через Service Engines. Весь цикл развертывания Service Engines полностью автоматический.

Avi Enterprise Edition лицензируется по числу vCPU компонентов Service Engines ("Service Core"), полностью поддерживается со стороны VMware, а лицензии доступны на 1 и 3 года. Скачать пробную версию продукта можно по этой ссылке.

Весной этого года компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Основные улучшения знает большинство администраторов, так как об этом писали достаточно подробно. Но есть и несколько небольших, но важных изменений, знать про которые было бы очень полезно. Давайте на них посмотрим...

На днях компания VMware объявила о доступности для загрузки VMware Cloud Director 10.3, решения для сервис-провайдеров, предоставляющих виртуальные машины в аренду, которым нужна интегрированная платформа управления облаком. Напомним, что о прошлой версии этого продукта (10.2) мы писали весной этого года вот тут.

Давайте посмотрим на основные новые возможности VCD 10.3:

• Поддержка Kubernetes - тут появились такие новшества, как поддержка кластеров Tanzu Kubernetes для NSX-T Data Center group networking. Теперь для отдельных сервисов можно включить внешний доступ в рамках data center group.
• Сервис-провайдеры и клиенты могут делать апгрейд кластеров Tanzu Kubernetes с использованием графического интерфейса, а также использовать vRealize Operations Tenant App для учета потребления ресурсов Kubernetes.
• Клиенты могут использовать единую точку доступа API для всех операций жизненного цикла решений Tanzu Kubernetes Grid Service, Tanzu Kubernetes Grid и непосредственно Kubernetes.
• Улучшения интерфейса по работе с режимом FIPS-compliant.
• Поддержка в API приложений vApp при их перемещении между vCenter.
• Улучшения интерфейса при работе с каталогом.
• Поддержка VMware Cloud Director Service Library для vRealize Orchestrator 8.x (для этого есть vRealize Orchestrator plug-in, который позволяет имплементировать рабочие процессы vRO для клиентов VCD).
• Улучшенные функции поиска Quick Search и Global Search в интерфейсе.
• Улучшения производительности расширения Auto Scaling.
• Поддержка vApp network services в окружении NSX-T - вы можете использовать NAT, фаервол и статическую маршрутизацию для сетей виртуальных приложений vApp.
• Поддержка Distributed Firewall Dynamic Group Membership в окружении NSX-T - можно создавать группы безопасности ВМ с динамическим членством, которое основано на базе различных параметров ВМ (например, шаблон имени или тэги). Для таких групп можно создавать правила фаервола, что позволяет микросегментировать сетевой трафик и эффективно защищать группы ВМ.
• Сервис-провайдеры могут создавать внешние сети на базе VLAN и оверлеев сегментов NSX-T Data Center.
• Сервис-провайдеры могут импортировать сети на базе DVPG. Администратор может импортировать распределенную портгруппу из Distributed Switch и расшарить эти сети между группами датацентра.
• Поддержка VLAN и пулов port-group network pools для VDC на базе NSX-T Data Center.
• Поддержка создания VDC без ассоциации с NSX Data Center for vSphere, NSX-T Data Center Update port groups или внешними сетями.
• Поддержка решений Avi версий 20.1.3 и 20.1.4.
• Поддержка конфигурации DHCPv6 и SLAAC, а также назначения primary IP address шлюзу NSX-T edge gateway в интерфейсе.
• Поддержка создания и управления статическими пулами IPv6.
• Просмотр списка VDC group networks в интерфейсе.
• Улучшения назначений для Edge Cluster.
• Поддержка управления DHCP для изолированных сетей в VDC на базе NSX-T Data Center.
• Сервис-провайдеры могут менять основные настройки Avi SEG.
• Новый раздел Tier-0 Gateway Networking на портале Service Provider Portal.
• Аллоцированные IP-адреса DHCP видны на экране VM details.
• Можно изменять и удалять DHCP-пулы из сетей на базе NSX-T Data Center.
• Действие Reject для правил фаервола NSX-T Data Center edge gateway (также можно нотифицировать клиента о заблокированном трафике).
• Можно изменять приоритет правил NAT.
• Поддержка Reflexive NAT.
• Поддержка импортированных сетей VMware Cloud on AWS.
• Для внутренних подсетей поддерживаются службы Advertise services с механизмом route advertisement.
• Поддержка сетей /32 в качестве внешних для NSX-T Data Center.
• Поддержка Guest VLAN Tagging для сегментов сетей NSX-T Data Center.
• Доступность Alpha API - теперь администраторы могут использовать включенный по умолчанию API, который позволяет управлять кластерами Kubernetes Container Cluster, а также предоставляет возможности Legacy API Login.

Более подробную информацию о новом релизе VMware Cloud Director 10.3 можно получить в Release Notes. Скачать его можно по этой ссылке.

Недавно компания VMware объявила о выпуске новой версии средства для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре vRealize Network Insight 6.3 (vRNI + также версия Cloud). Напомним, что о прошлой версии продукта мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном vRNI / Cloud версии 6.3:

1. Поддержка VMware Cloud on Dell EMC

Как и для других облачных и онпремизных инфраструктур, vRNI теперь предоставляет для VMConDellEMC такие возможности, как обнаружение приложений (Application Discovery), планирование миграций, планирование стратегии безопасности, алерты и аналитику, а также детализированные дэшборды вашего окружения.

2. Дэшборд VMware SD-WAN Gateway

Новый дэшборд VMware SD-WAN Gateway показывает производительность и использование шлюзов VMware SD-WAN Edges во всей вашей инфраструктуре SD-WAN.

Для каждого VMware SD-WAN gateway можно посмотреть отдельный дэшборд, как показано на картинке ниже:

Здесь можно увидеть топологию, включающую в себя туннели между VMware SD-WAN Edge и выбранным шлюзом, а также состояния этих туннелей. Для каждого из туннелей можно увидеть метрику Quality of Experience, а также множество других полезных мелочей.

3. Настройка Polling Intervals

Теперь можно настроить периодичность сбора данных со стороны vRNI для компонентов сети, а также сделать сбор данных по запросу. По умолчанию данные собираются каждые 10 минут, но вы можете выбрать и достаточно большой интервал:

Кастомный интервал можно задать и в минутах:

Если вы хотите запустить мгновенный сбор данных прямо сейчас, то вы можете найти опцию Collect Now в разделе Accounts and Data Sources:

4. Функции Network Assurance and Verification

Теперь карту Network Assurance and Verification Network Map можно отобразить на полный экран, что позволяет визуализовать на больших мониторах все компоненты виртуальной и физической инфраструктуры и получить сводную информацию обо всех проблемах и алертах:

Можно убрать лишние элементы и показать "диспетчерский" вид:

 Также в продукте есть Intent library для проверки соответствия конфигураций VRRP и HSRP на active и standby маршрутизаторах:

5. Метрики NSX-T Manager Network Utilization и топ 25 ВМ

Так же, как и Network Utilization Dashboard в разделе VMware Cloud SDDC, теперь в vRNI есть такой же дэшборд и для NSX-T Manager. Network Utilization Dashboard предоставляет детальные метрики, которые включают в себя Network Traffic Rate, а также Packets per Seconds для Tx и Rx, отображаемые в различных форматах:

Также есть вывод списка топ-25 виртуальных машин по значениям метрик network traffic rate и packets per second:

6. Прочие улучшения

• Алерты и тренды для VMware Cloud on AWS configuration maximums (относящиеся к Network и Security)
• Поддержка Platform XL Clusters до 15 узлов
• 40+ событий NSX-T, которые были оптимизированы для near-real-time notification
• Метрики vSAN Datastore

Узнать больше о продукте vRealize Network Insight 6.3 и получить пробную версию можно на этой странице.

Источник.

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

На днях компания VMware обновила свое основное средство для автоматизации рутинных операций в облаке на базе vSphere, выпустив vRealize Automation 8.4.2. Несмотря на то, что это минорный релиз, в продукте появилось довольно много всего нового. В прошлый раз о vRA мы писали вот тут.

Давайте посмотрим на новые возможности VMware vRA 8.4.2:

• Диски, добавленные через vRealize Orchestrator, и расширения теперь показываются в диаграмме развертывания (топология)
• Возможности шифрования Microsoft Azure disk encryption, которые поддерживают:
  • Disk Encryption для independent managed disks
  • Disk Encryption для действия Add Disk (Day 2 action)
• Группы Property groups теперь могут:
  • Использовать рабочие процессы vRO для задания свойств внешних динамических значений
  • Привязывать пароли к property groups для использования разных паролей для разных групп
• Теперь можно назначить одинаковые диапазоны IP-адресов, которые приходят от внутреннего или внешнего IPAM, для разных сетей
• События Provider Events срабатывают, когда тенант вызывает одно из действий CRUD (Create, Read, Update, and Delete)
• Настраиваемый лимит max number of supervisor namespaces, который определяет максимальное число пространств имен для проекта в заданной зоне Kubernetes
• Управление снапшотами Microsoft Azure disk snapshot management теперь поддерживает:
  • Выявление снапшотов
  • Действие по удалению снапшота (Day 2 action)
  • Совместимость Managed Disk Snapshot – поддержка параметров Resource Group, Encryption set, Network policy и Tags

Более подробно о новых возможностях и изменениях в API решения VMware vRealize Automation 8.4.2 можно прочитать в Release Notes. Скачать vRA можно по этой ссылке.

В начале года компания VMware запустила обновленный портал VMware Customer Connect, пришедший на смену устаревшему и неповоротливому My VMware, использовать который, зачастую, было мучением. Теперь VMware повернулась к пользователям лицом - на портале Customer Connect можно решать основные рутинные задачи, связанные...

Многие сетевые администраторы используют решение VMware vRealize Network Insight (vRNI), предназначенное для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в виртуальном датацентре. Также в средних и крупных компаниях для управления тикетами используется ITSM-система ServiceNow, которая, помимо прочего, позволяет управлять инцидентами различного характера в ИТ-инфраструктуре, в том числе, виртуальной.

Сегодня мы посмотрим, как можно интегрировать эти решения через почту, чтобы администраторы получали оповещения об инцидентах в сфере сетевой безопасности в консоли ServiceNow. Для vRNI вам понадобится административный доступ, а для ServiceNow - права для создания инцидентов и входящих действий (inbound actions).

Сначала вам потребуется найти системный email-адрес ServiceNow. Например, для облачного продукта ServiceNow Cloud это адрес instancename@serive-now.com. Посмотреть данный адрес можно в разделе System Mailboxes -> Administration -> Email Accounts -> ServiceNow SMTP:

Затем в консоли vRNI нужно настроить отсылку почтовых нотификаций в ServiceNow для нужных алертов. Для этого идем в Settings -> Alerts and Notification -> Alerts:

Открываем нужный алерт, выставляем частоту отсылки сообщений и выбиваем почтовый адрес ServiceNow:

Теперь нужно создать Inbound Action для создания инцидента в ServiceNow. Идем в ServiceNow -> System Policy -> Email -> Inbound Actions -> New:

Там задаем имя инцидента, целевую таблицу и тип действия Record Action:

На вкладке Action нужно создать кастомный скрипт для обработки и кастомизации полей полученного сообщения:

Вот пример такого скрипта:

current.caller_id = gs.getUserID();
current.comments = "received from: " + email.origemail;
current.short_description = email.subject;
current.description = email.body_text.toString();
current.category = "network";
current.incident_state = IncidentState.NEW;
current.notify = 2;
current.contact_type = "email";
if (email.body_text.toString().indexOf('Critical') >=0 ){
 current.impact=1;
 current.urgency=1;
}
else if (email.body_text.toString().indexOf('Info')>=0 ){
 current.impact=2;
 current.urgency=3;
}
else if (email.body_text.toString().indexOf('Moderate')>=0 ){
 current.impact=2;
 current.urgency=2;
}
else if (email.body_text.toString().indexOf('Warning')>=0 ){
 current.impact=1;
 current.urgency=2;
}
if (email.body.assign != undefined)
 current.assigned_to = email.body.assign;
current.insert();

В этом скрипте можно задать параметры фиксируемого инцидента, такие как его критичность, срочность и т.п. Также вы можете написать свой сценарий на базе документации к ServiceNow. Инциденты будут отображаться в разделе Incident -> All.

Источник.

Компания VMware анонсировала обновление решения VMware HCX 4.1, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о версии HCX 4.0 мы писали весной этого года вот тут.

Давайте посмотрим, что нового в HCX 4.1:

1. Предиктивные оценки для пакетных миграций

В версии 4.0 появилась оценка пакетных миграций (Bulk Migrations), а в версии 4.1 появился драфтинг процесса оценки пакетных миграций, что позволяет быстро сделать прикидку по времени переноса ВМ:

2. Seed Checkpoint для пакетных миграций

Раньше при пакетной миграции больших виртуальных машин на базе репликации в случае неудачной миграции происходило уничтожение данных реплик на целевой площадке, что могло привести к потере данных состояний миграции за несколько дней. Теперь же можно создать контрольные точки репликации, которые можно повторно использовать в случае неудачного завершения миграции. Включается это в Migration Wizard:

3. Финальная доступность Mobility Optimized Networking (MON)

Эта возможность позволяет включать маршрутизацию трафика виртуальных машин, переносимых в онпремизное или публичное облако, через облачный шлюз, вместо использования маршрутизации через роутер на исходном сайте.

Это позволяет избежать hairpin-эффекта:

4. Увеличенные максимумы VMware HCX

Теперь лимиты максимальных конфигураций были увеличены еще больше:

Скачать VMware HCX 4.1 можно по этой ссылке, Release Notes доступны тут.

После выхода VMware vSphere 7 Update 2 появилось много интересных статей о разного рода улучшениях, на фоне которых как-то потерялись нововведения, касающиеся работы с большими нагрузками машинного обучения на базе карт NVIDIA, которые были сделаны в обновлении платформы.

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

Давайте посмотрим на все это несколько подробнее:

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

Оптимизации включают в себя не только средства разработки, но и развертывания и масштабирования, которые теперь удобно делать на виртуальной платформе. Все это привело к тому, что накладные расходы на виртуализацию у задач машинного обучения для карточек NVIDIA практически отсутствуют:

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

В таком режиме виртуальные машины оказываются полностью изолированы на уровне аппаратного обеспечения. Выбор профилей для MIG-режима выглядит так:

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

Мы несколько раз писали об онлайн-сервисе VMware vSphere DRS Dump Insight, который позволяет показывать различную информацию по перемещению виртуальных машин в кластере DRS на портале самообслуживания, куда пользователи могут загружать файлы дампов.

Это позволяет вам получить ответы на следующие вопросы:

• Какие рекомендации DRS сделал на основе анализа cost/benefit
• Почему DRS сделал именно эту рекомендацию
• Почему DRS вообще иногда не делает рекомендаци для балансировки кластера
• Как кастомное правило affinity/anti-affinity влияет на балансировку в кластере
• Где взять полный список рекомендаций DRS

На днях у VMware вышло руководство пользователя по этой утилите, которое будет интересно почитать всем администраторам кластеров VMware DRS, решившим начать анализировать дампы DRS:

DRS Dump Insight User Guide небольшой и занимает всего 20 страниц, но там есть очень конкретные рекомендации по работе с интерфейсом утилиты и по трактовке ее результатов:

Напомним, что DRS Dump Insight в целом может делать следующие вещи:

• Автоматизация воспроизведения дампов (с помощью встроенных кастомных DRS replayers)
• Предоставление и визуализация дополнительной информации, которая недоступна в обычных анализаторах логов
• Парсинг и анализ логов для понимания и наглядного отображения решений балансировщика DRS
• Генерация итогового результата в текстовом формате

Скачать VMware vSphere DRS Dump Insight User Guide можно по этой ссылке.

Недавно мы рассказывали про новую возможность KB Insights, которая появилась в решении VMware vRealize Log Insight Cloud. На днях VMware объявила о выпуске еще одного обновления этого облачного продукта для аналитики лог-файлов и мониторинга инфраструктуры.

Одной из новых возможностей июньского релиза Log Insight Cloud стала возможность Live Tail для логов, в которых вы ищете источники проблем. Этот механизм позволяет в реальном времени "прицепиться" к файлам журнала, например, определенного хоста и отслеживать там нужные вам параметры.

На примере ниже коллеги из VMware разбирают эту функциональность. Допустим, у вас возникла проблема с одним из веб-серверов, который дает необычные всплески трафика, и вы хотите понять, почему. С помощью Live Tail можно понять, какой IP-адрес соединяется с сервером и отследить, что происходит с трафиком данного приложения:

Тут рабочий процесс может выглядеть следующим образом:

• Добавляем ключевое слово, например, имя вебсайта
• Добавляем log_type для сужения области отслеживания, в данном случае Apache
• Добавляем фильтр, чтобы убедиться, что мы отслеживаем только те логи, где есть поле remote_host
• Добавляем колонку remote_host, чтобы видеть в реальном потоке, с какими хостами происходят соединения

Перейти в представление Live Tail можно по кнопке в правом верхнем углу раздела Export Logs:

Любой запрос можно добавить в Избранное (создать Favorite Query), после чего его можно выбирать для отслеживания в режиме Live Tail:

Для фильтрации можно использовать составные фильтры по множеству условий:

Ключевое слово подсвечивается в самом логе:

Live stream можно останавливать и запускать снова, а элементы лога можно развернуть, чтобы посмотреть детали записи:

Отображаемые колонки можно добавлять и удалять:

Также есть ролевая модель доступа, то есть теперь, например, вы можете дать права администраторам приложений с ограничениями, чтобы они сами разбирались в своих проблемах:

Помимо функций Live Tail, в июньском релизе были также добавлены новые дэшборды и запросы для AWS и Azure.

Так теперь выглядят новые интеграции для AWS:

Например, вот дэшборд EventBridge Overview:

А вот все дэшборды для EventBridge:

Ну а вот так выглядят новые интеграции для Azure:

Если вы хотите попробовать поработать с VMware vRealize Log Insight в облаке AWS или Azure, то VMware предоставляет пробную версию на 30 дней.

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

Компания VMware анонсировала новую возможность KB Insights, которая стала доступна в облачной версии решения для аналитики лог-файлов и мониторинга инфраструктуры VMware vRealize Log Insight Cloud.

С помощью KB Insights можно проанализировать проблемы облачной виртуальной инфраструктуры, которые выявляются вследствие анализа логов, и получить соответствующие ссылки на статьи VMware Knowledge Base и VMware Community, которые помогут в их решении.

Эта функция использует как поиск соответствующих совпадений в сообщениях лог-файлов, так и алгоритмы машинного обучения для вывода нужных статей базы знаний VMware.

Вот пример аналитики Log Insight Cloud, которая выявила проблемы по недоступности виртуальной машины в сети, случавшейся время от времени:

Оказалось, что эта проблема связана с дублированием IP-адреса в какой-то момент. Функция KB Insights предложила как ветку обсуждений этой проблемы на VMware Community, так и релевантную статью базы знаний "Duplicate IP address detected (1020647)".

Статья KB рассказывает о том, как изменить IP-адрес для найденного MAC-адреса устройства, а вот статья на комьюнити рассказывает о том, как найти второй сервис, где торчит тот же самый IP-адрес, чтобы решить, какой из адресов нужно поменять. Это решение, конечно же, дает администратору больше гибкости:

Для каждого предлагаемого инсайта есть лайк и дизлайк - он позволяет администратору постепенно улучшать систему рекомендаций, которая и формируется, в том числе, на базе такого фидбэка. Кстати, в красном боксе приведен текст в лог-файле, по которому были найдены инсайты:

Есть также кнопка Explore Logs, которая поможет вам понять причину проблемы, взглянув на содержимое лог-файла:

Ну и далее можно настроить алерт по электронной почте для случая, когда данная проблема повторится вновь:

Источник.

На днях компания StarWind, ведущий производитель средств для создания программно-аппаратных хранилищ под виртуализацию, выпустила новую версию своего флагманского продукта - StarWind Virtual SAN v8 for Hyper-V (build 14120). Надо отметить, что в конце марта этого года StarWind уже выпускала обновление Virtual SAN (build 14033), поэтому ниже мы расскажем о новых возможностях обеих версий.

Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:

1. Компоненты VTL и Cloud Replication

• Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
• Возможность Write Protect для виртуальных кассет.
• Минимальный размер кассеты установлен в 50 МБ.
• Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
• Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
• Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.

2. Улучшения синхронной репликации

• Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
• Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
• Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
• Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
• Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
• Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
• Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.

3. Основные улучшения

• Улучшения производительности для версии VSA (Virtual Storage Appliance).
• Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
• Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
• Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
• Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
• Было обновлено лицензионное соглашение.

4. StarWindX PowerShell Module

• Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
• Добавлено свойство MaintenanceMode для объекта HA Device.

Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.

Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

Еще в 2019 году компания VMware анонсировала утилиту VMware Usage Meter 3.6.1 для vCloud Availability 3.x, которая позволяла автоматически измерять потребление облачных ресурсов и создавать отчеты на помесячной основе. Предназначено это для облачных провайдеров, предоставляющих услуги аренды виртуальных машин по модели IaaS. На днях была анонсирована новая версия Usage Meter 4.4, которая расширяет функциональность версии 3.6.1.

Давайте посмотрим, что там появилось нового:

1. Ежемесячные отчеты

Новая возможность Usage Meter позволяет привязать метку (label) к каждому клиенту и на базе нее отслеживать потребление ресурсов, формируя ежемесячные отчеты. Это делается за счет применения механизма правил к объектам vCenter или VMware Cloud Director.

2. Поддержка LDAP

Теперь облачные администраторы могут залогиниться в виртуальный модуль Usage Meter с использованием аутентификации LDAP. Более подробно об этом можно почитать вот тут.

3. Офлайн отчеты

Ранее отчеты UM были доступны только после утверждения со стороны поддержки VMware, теперь же они доступны всем. Настроить их можно при развертывании виртуального модуля vCenter Server в формате OVA, где можно настроить обход валидации Usage Insight registration.

Тем не менее, все отчеты генерируются только на стороне Usage Insight, а офлайн-возможности позволяют делать их ручной импорт и экспорт.

4. Улучшения механизма апгрейда

В прошлом апгрейд Usage Meter 4.X использовал файл SHAR, который загружался в Usage Meter, после чего выполнялся скрипт апгрейда. Теперь в версии 4.4 для этого используется ISO-образ, который можно привязать к любому виртуальному модулю Usage Meter 4.1+ и выполнить сценарий из ISO-образа как Root.

Ну и напоследок небольшое обзорное видео о развертывании Usage Meter:

Для использования возможностей Usage Meter вам нужно переключиться на Flex Pricing Model, что является обязательным требованием:

Скачать VMware Usage Meter 4.4 можно по этой ссылке.

На сайте проекта VMware Labs появилась новая версия утилиты Virtual Machine Compute Optimizer 3.0, о которой в последний раз мы писали летом 2019 года. С тех пор вышло несколько обновлений этого средства. Напомним, что VMCO - это PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

В третьей версии сценария появился рабочий процесс установки/апгрейда всех необходимых модулей - VMCO и PowerCLI. Теперь это единый сценарий, в котором есть мастер, проходящий по всем шагам установки модулей, соединения с vCenter и экспорта результатов.

Также в последних версиях была добавлена опция -simple, которая позволяет отобразить только информацию о виртуальных машинах (без серверов vCenter, кластеров и хостов ESXi), обновлена документация и исправлено много ошибок.

Скачивайте Virtual Machine Compute Optimizer 3.0 и выясняйте, правильно ли у вас настроены vCPU и Memory для виртуальных машин. Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри.

На сайте проекта VMware Labs появилось обновление утилиты VMware Event Broker Appliance (VEBA) v0.6. Напомним, что это решение, которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That". О версии VEBA 0.5, вышедшей в декабре прошлого года, мы писали вот тут.

Давайте посмотрим, что нового в VEBA 0.6:

1. Функции Embedded Knative

Еще в прошлой версии VEBA поддерживал serverless-приложения Knative в качестве процессора событий, теперь же эта опция выбрана по умолчанию. Делать ничего не потребуется, нужно просто нажать Next.

2. Интеграция с пользовательским интерфейсом vSphere Client

Теперь в клиенте можно установить плагин VMware Event Broker, который доступен из инвентаря (только для варианта развертывания Knative):

В плагине есть 3 блока функций VEBA:

• Events – это первая точка настройки событий vCenter Server. Пользователям теперь не нужно ковыряться в репозитории vCenter Event Mappings repo, они могут видеть все события в окружении vCenter.
• Functions - здесь можно увидеть все развернутые функции и создавать переменные окружения.
• Secrets - здесь задаются пароли (secrets), используемые в функциях.

Для регистрации плагина VEBA понадобится доступ к vCenter Server:

3. Поддержка PowerShell для Knative

VEBA использует механизм CloudEvents для преобразования событий vCenter Server в рабочую нагрузку, которая может потребляться сценариями PowerShell. PowerShell SDK для CloudEvents опубликован в PowerShell Gallery, запустить его установку можно командой Install-Module CloudEvents.Sdk:

4. Репозиторий Knative Sample Functions

Для помощи новичкам был создан репозиторий по адресу: https://vmweventbroker.io/examples-knative. Пока есть сценарии реализации на PowerShell, но скоро будут добавлены примеры на Python и Go.

5. Просмотрщик vSphere CloudEvents Viewer

С помощью сервиса Sockeye по адресу https://[FQDN-VEBA]/events можно увидеть просмотрщик событий vCenter Server, которые можно фильтровать:

Фильтры можно группировать с помощью элемента + Add Filter:

Можно также скопировать сгенерированный JSON для события, чтобы самостоятельно симулировать его в окружении vCenter.

Более подробно о функциях новой версии VMware Event Broker Appliance 0.6 можно почитать в статье Вильяма Лама. Скачать последнюю версию виртуального модуля можно тут. Ну и небольшой видеообзор от коллег, имеющих непосредственное отношение к выпуску обновления:

Данные играют значимую роль в жизни любой компании. Представляя собой ценный актив, важно обеспечить их целостность и доступность. Для достижения этой цели, требуется комплексный подход, сочетающий в себе использование лучших решений и технологий.

Эксперты #CloudMTS?, Veeam и Huawei на онлайн-конференции ИТ-ГРАД рассказали об особенностях построения надежной инфраструктуры и сценариях использования современных BaaS-средств в публичных, частных и защищенных IaaS ФЗ-152 облаках.

На днях компания VMware анонсировала новую версию пакета для интеграции мониторинга vRealize Operations (vROPs) и инфраструктуры виртуальных ПК - vRealize Operations Management Pack for Horizon 1.1. Это решение предназначено для мониторинга виртуальных десктопов, обнаружения аномалий и оптимизации VDI-инфраструктуры. Напомним, что первая версия этого пакета вышла в октябре прошлого года.

Пользователи продукта vRealize Operations Advanced / Enterprise, vRealize Suite, а также облачной подписки vRealize Cloud Universal смогут включить пакет vRealize Operations Management Pack for Horizon через vRealize Operations Marketplace. Давайте посмотрим, что нового появилось в версии 1.1:

1. Обновленные дэшборды

Почти на всех дэшбордах были добавлены новые информационные блоки и оптимизированы старые. В представлении Horizon World Overview стало еще больше всего полезного, также теперь все более наглядно:

2. Поддержка Login Duration Metrics

Администраторы теперь могут видеть более детальную информацию касательно метрик логина пользователей во всем окружении Horizon. Например, можно быстро увидеть пользователей, у которых логин происходит очень медленно. После этого можно искать причину этих процессов, используя инструменты траблшутинга.

3. Повявились дэшборды Pools & Farms

Они предоставляют больше информации, относящейся к доступности, состоянию и жизнедеятельности пулов или фермы. Ключевые KPI-индикаторы подсвечены так, чтобы администраторы могли на них сфокусироваться.

4. Метрики RDS Capacity и Disparity

В этой версии появилась возможность понять оставшееся количество сессий в отдельной RDS-ферме. Администраторы могут изолировать любые RDS-хосты, которые имеют "нетипичный" уровень производительности, за счет анализа несоответствий соединений. Если в ферме RDS есть непропорциональная загрузка хостов, значит имеет место какой-то затык по производительности. Эти новые метрики позволят администраторам лучше находить причины проблем, связанных с неправильными конфигурациями.

5. Новые алерты

Следующие алерты были добавлены в версии 1.1 пакета:

• Notification Event Alert on GET API Failure on object Collection
• Notification Event Alert on Pod for collection failures
• Notification Event Alert on Help desk API Failure
• Notification Event Alert on relationship Failure
• Notification Event Alert on Version Issues
• Data collection failed on the Horizon Connection Server
• Horizon adapter collection time is going beyond default threshold limit
• Average Application Session Helpdesk API response time above threshold
• Average VDI session Helpdesk API response time above threshold
• Average RDS desktop Session Helpdesk API response time above threshold

Скачать vRealize Operations Management Pack for Horizon 1.1 можно из маркетплейса VMware по этой ссылке. Также попробовать этот пакет можно в рамках лабораторной работы на Hands-on Labs. Release notes доступны тут.

На сайте проекта VMware Labs недавно обновился основной клиент для управления инфраструктурой vSphere - VMware vSphere Client, а через пару дней после этого обновился и мобильный клиент - вышел vSphere Mobile Client версии 2.2. Напомним, что последний раз об этом клиенте мы писали летом прошлого года вот тут.

Давайте посмотрим, что нового появилось в мобильном клиенте, начиная с версии 2.0:

• Добавлена поддержка VMware Cloud в части VMware Cloud on AWS, что позволяет получить доступ к облачным серверам через мобильное устройство
• Добавлен фильтр по серьезности проблем в разделах Alarm и Events
• Добавлена клавиша Windows в виртуальной клавиатуре и для сочетаний клавиш
• Улучшена стабильность консоли ВМ при повороте устройства
• Добавлена забытая кнопка Back в разделах страниц логина
• Обновлены иконки и сплэш-скрины
• Теперь на странице деталей ВМ есть навигация по связанным объектам
• Страница деталей виртуальной машины грузится быстрее, когда ВМ выключена

Скачать vSphere Mobile Client 2.2 можно по этим ссылкам:

• vSphere Mobile Client for Android devices
• vSphere Mobile Client for iOS devices

Также не забудьте посмотреть инструкцию о развертывании Notification Service, чтобы включить Push-уведомления на своих устройствах. Его можно развернуть в одном из двух вариантов:

• Как OVA виртуальный модуль
• Как контейнер Docker

Ну и немного устаревшее, но еще не полностью потерявшее актуальность видео о версии 1.13:

На ресурсе интерактивных лабораторных работ VMware Hands-On Labs появилось 2 лабы, посвященных сервису VMware Skyline. Напомним, что Skyline - это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для Enterprise-продуктов с целью предотвратить возникновение проблем в будущем на базе анализа текущего состояния виртуальной среды.

Лабораторные работы, как ни что другое, помогут вам понять, нужен ли вам тот или иной продукт VMware на самом деле или нет.

Вот небольшое видео о том, как зарегистрироваться на ресурсе Hands-on Labs, найти эти лабораторные работы и приступить к их выполнению:

Работает это в любом браузере, не требует никаких установок, но главное - полностью бесплатно. Посмотреть весь каталог HoL можно по этой ссылке. Кстати, там уже набралось более 120 лабораторных работ, в создании которых принимало участие более двух сотен инженеров.

Клиентам новой площадки доступен весь спектр услуг «ИТ-ГРАД». Сервис актуален для компаний, которые используют облачные технологии для цифровизации бизнеса. Для связи между площадками используются выделенные каналы, позволяющие предоставлять заказчикам геораспределенные сервисы.

Облачная среда запущена с использованием высокочастотных процессоров Intel Xeon Gold 6248R с базовой тактовой частотой 3ГГц, а также Intel Xeon Platinum 8268 с частотой 2,9 ГГц. Новые процессоры обеспечивают высокую производительность клиентских приложений, чувствительных к частоте процессора, таких как 1С и SAP.

В качестве платформы виртуализации «ИТ-ГРАД» использует VMware vSphere 7.0. Для управления виртуальной инфраструктурой заказчикам предоставляется персональный портал самообслуживания. Для размещения данных используются системы хранения Huawei Dorado 8000 v6 в состав которых входят быстрые твердотельные накопители с поддержкой технологии NVME. Этот тип дисков подходит для размещения высоконагруженных ERP-систем. Резервное копирование и восстановление данных в облаке осуществляется с помощью системы Veeam Backup & Replication 11.

«Спрос на облачные сервисы растет с каждым годом и «ИТ-ГРАД» увеличивает количество площадок для обеспечения потребностей бизнеса. Linxdatacenter стал нашей пятой облачной площадкой, наряду с дата-центрами в Москве, Санкт-Петербурге и Алматы. Клиенты облака имеют единый высокий уровень сервиса на всех локациях», – прокомментировала генеральный директор «ИТ-ГРАД» Ирина Харченко. 

Подробнее о Linxdatacenter:

Linxdatacenter входит в топ-5 провайдеров услуг ЦОД в РФ в 2020 году по версии CNews. Дата-центр в Санкт-Петербурге расположен по адресу: ул. Репищева, д. 20А.

Площадка соответствует уровню надежности TIER III по стандарту TIA-942 и методологии Uptime Institute, подтвержденному сертификатом Uptime Institute Management & Operations Stamp of Approval.

Оригинал статьи на сайте ИТ-ГРАД.